一场向应用交付标准的“冲锋”
回顾过去信息产业几十年的发展历史，整个行业存量的数千万台服务器，在集群管理、资源切分供给、资源调度、任务编排、应用交付、应用运维等领域，一直没有形成标准和规范。几年前一份行业调研显示，全球服务器平均资源利用率不超过 10%，这里面存在巨大的社会资源浪费，也存在巨大的优化空间。
云计算的发展使这些问题变得可以解决了。基础设施逐渐向云上迁移的过程中，催生了容器和 Kubernetes 的迅速流行，也为上述领域构建统一的标准，不同云厂商间 IaaS 的差异性被屏蔽，使用户在所有云环境中可以灵活使用资源，并且可以无缝的迁移和维护应用。
云原生的理念也因此得到快速普及。企业将越来越多的工作负载都迁移到 Kubernetes 之上，包括有状态或无状态的，比如微服务、大数据、AI、数据库、中间件等等。为了管理和运维这些应用，开发者不得不面对大量的底层 API，这形成了两个挑战。一方面，应用交付和管理标准的缺失，使各种工作负载都会形成自己的运维和管理平台，带来企业平台层的分化。另一方面，Kubernetes 对于业务开发者而言过于复杂，带来了很高的使用门槛和稳定性风险。
在 Kubernetes 和云原生技术对基础设施和工作负载层面的抽象逐渐统一的态势下，如何进一步简化和标准化应用交付与管理层面的操作和功能，成为接下来一个非常自然但重要的演化方向，也会成为市场真正需要角逐的战场。
2019 年阿里云与微软联合发布 OAM
2018年前后，阿里云云原生团队和微软同时看到了这个方向，在一次于阿里硅谷中心的深度交流和头脑风暴后，双方当即决定联合起来，共同孵化这个应用交付与管理体系，并于 2019 年联合发布了应用标准化模型 OAM（OpenApplicationModel），为云原生生态的应用平台建设提供理论依据。
OAM 的开源引发了业界不小的震动，不少企业都在进行积极的推广验证，这其中当然包括阿里的多个产品线。然而一段时间之后，阿里云云原生团队意识到要真正解决用户的问题，只靠模型还远远不够。由于没有具体的实现方案，仅遵循 OAM 模型的思想，仍会使系统之间形成巨大差异，特别是在规模较大的场景下。比如阿里内部就形成了多套实现，能力无法复用，应用间也不能互通。而在社区的推进过程中，得到的更多反馈是 OAM 模型没有实现，很难落地使用。因此云原生团队下决心要把 OAM 的实现做出来，并且是以开源的方式去做，这也是来自社区的呼声。
KubeVela 开源团队在沟通技术实现细节
KubeVela 就此诞生。
KubeVela 诞生于 OAM 社区，也是第一个将“以应用为中心”的设计理念落地的项目。发展到 2021 年 5 月，阿里云联合信通院发布业内首个以 OAM 为核心的“云计算开放架构”标准，将 OAM“模型”化虚为实，也对 KubeVela 后来的发展起到关键作用，推动其成为一个真正意义上的跨云应用交付与管理平台。
2021 年阿里云与信通院联合发布开放应用架构标准
凭借过去做云产品的经验积累，KubeVela 团队深知一个新技术想要顺利推广，很重要的一点是在解决原有问题的同时，尽可能降低用户采纳的成本。社区对之前的实践和功能做了充分兼容。当 KubeVela 发布第一个正式版本的时候，用户做的操作更像是升级而不是使用一个全新的系统。为了保证社区后续的演进不偏离这个路线，在设计之初 KubeVela 创始团队就定下了一些核心原则，指导整个 KubeVela 开源社区的长期发展。
（1）兼顾用户友好和可扩展性
KubeVela 基于 OAM 模型提供用户友好的上层抽象，但这些抽象可以随时扩展以满足用户的各种需求。这就避免了 KubeVela 项目成为了一个只能解决“最小公分母”问题的“鸡肋”项目。这是一个非常重要的创新。
（2）可编程
而在众多的可扩展性设计中，KubeVela 最终选择了 Infra as Code 的可编程扩展方式。因为这种扩展方式不仅简单易用，还可以方便的模块化和插件化。这个选择不仅提供了扩展 KubeVela 的最佳方案，还为后来的插件市场等生态能力打下了基础。
（3）以工作流为核心的交付模型
在 KubeVela 被开源社区逐步采用的过程中，根据大量的用户反馈和调研显示，看似非常碎片化和复杂的各类应用交付与管理场景，其背后确实是有一个非常本质的基础模型存在的。这个基础模型就是“工作流”，所以在 KubeVela 创立后，团队很快就开始同时演进 OAM 模型本身，引入了“工作流”这个基础模型并且在 KubeVela 实现了一个非常轻量级的工作流引擎。而“工作流”这个特性本身就又与 Kubernetes 和 GitOps 生态天然互补，所以这个关键创新很快就成为了 KubeVela 被大量采用的”杀手锏“。
（4）以业界最广泛和最真实的场景作为项目演进指南针
KubeVela 的发展过程中，大量关键的设计比如对交付 Helm 组件的完善支持、基于 GitOps 的核心交付流程、以多集群 / 多云 / 混合云环境作为首要交付目标等，都是结合阿里内部大规模实践，同大量的开源社区用户一起打磨、设计、然后最终实现出来的。这也是为什么很多人评价 KubeVela 是一个非常接地气的项目。这种基于阿里最佳实践但又紧贴业界最广泛场景的演进方式，对于 KubeVela 项目的广泛采用，做出了至关重要的贡献。
云原生时代的工具和技术百花齐放，对于企业来说，如何将这些丰富的技术快速落地为我所用，是一个很大的挑战。KubeVela 的价值就在这里。如果做一个类比的话，它有点像云原生生态的 “Spring 框架”。在 Java 生态中，开发者可以通过 Spring 快速构建业务应用，使用一致的编程模型、不需要了解各类技术框架的细节，从而能够大幅降低技术门槛。相对应的，KubeVela 是将云原生技术组件和企业应用连接起来，建立管理和运维交付的标准，让开发者对云原生的关注点从 Kubernetes 向应用平台升级。
OAM 先进的理念、社区的用户基础加之阿里内部大规模的实践检验，使 KubeVela 初期的发展非常顺利，正式发布的第一周就冲上了 GitHub 的 Go 语言项目的趋势榜榜首。
同时，它也不可避免地遇到了刚起步的开源项目都可能遇到的问题。
首先，开源项目要成功的一大关键就是用户初始体验，而早期团队一般会更注重产品能力研发。KubeVela 本身的灵活性和可扩展性强大，这就导致第一个用例要么过于简单无法突出特色，要么过于复杂跑不起来。为了解决这些问题，团队开始重视安装复杂度、第一个用例的设计、文档结构的设计等等。直到现在，社区也一直在不断完善相关工具和文档，让初始用户可以低门槛体验项目。
第二， 可扩展性是 KubeVela 与生俱来的核心设计。但开始的时候，KubeVela 的扩展点众多，但是没有一个统一的概念，没有对应的工具链，因此，几乎没有社区开发者能够知道如何进行扩展。因此社区提出 Addon 的产品概念，将扩展能力以相对规范的形式进行开发、整合。投入开发者重点维护全链路工具，打通 Addon 的开发、存储、分发、升级机制。目前 Addon 的产品概念已成为 KubeVela 的特色之一。
第三，随着项目面临的场景越来越多、功能越来越丰富，KubeVela 不可避免地会遇到复杂性挑战。2021 年下半年，KubeVela 迎来 v1.1 版本，加入多集群管理的能力，同时也具备了通过工作流驱动整个交付过程的能力，这些都大大提升了 KubeVela 整个项目的可扩展性，但是也加剧了用户使用的门槛。也是在这时，KubeVela 团队意识到，项目的用户群体需要分层：下层是 PaaS 的构建者和运维，基于 KubeVela 的引擎能力去构建 PaaS，他们需要充分的灵活性和扩展性去适配企业内的不同场景；而上层是业务的开发者，相对来说他们更需要一个简单易用的平台，快速满足业务开发需求。于是，社区开启了一个新的项目 VelaUX, 以插件化的方式集成到 KubeVela 内核上，使用户可以通过点击一个插件实现安装一个直接开箱即用的平台。VelaUX 的出现也将 KubeVela 从以 Kubernetes 为主的技术性高扩展性项目实现向平台化高扩展性项目的跃迁。
相比于那些已经在公司内孵化好再开源的项目，KubeVela 是特殊的。它从第一天起就在社区发起、社区演进，甚至 KubeVela 这个名字也是由早期成员投票产生的。KubeVela 的初创团队邀请了许多 OAM 早期采纳公司的工程师一起来合作开发，保证项目核心部分的代码质量和稳定性。剩下的许多模块设计也都是在社区群策群力下完成的，比如官网的 UI 设计、命令行功能的使用方法、对于云资源支持的优先级等等，确保 KubeVela 许多用户体验方面的设计都建立在满足社区最广泛需求的基础之上，也保证了 KubeVela 项目贴近开发者的初心。
KubeVela 发展初期，团队成员每天打开 Github 页面都能看到大家给出的使用反馈、建议、以及代码贡献，这给了初创团队很深的感触和鼓舞。工程师在贡献开源的时候，其实都是在做自己喜欢的事情。如果一个人一直在做自己喜欢的事情，这本身就是一种强大的竞争力。KubeVela 社区也通过构建包容、开放、专业的协作环境，鼓励大家参与到开源建设中来，肯定每个人的工作，尊重每个人的价值。
从诞生之初， KubeVela 就是按照面向全球的开源项目去运作的。为使社区保持持续的生命力，2021 年 7 月，阿里云将 KubeVela 捐赠给 CNCF ，渐渐将影响力渗透到北美、日本、西班牙、英国等多个国家。如今，KubeVela 贡献者已经遍布全球，所在的企业和组织超过 70 个。不久前，KubeVela 正式晋升为 CNCF Incubation 项目，证明项目的影响力和成熟度得到业界认可。
KubeVela 社区的贡献者们
今天，企业对 KubeVela 的采纳程度正在快速提升。在阿里云内部，KubeVela 已经陆续成为 SAE、ACK One、EDAS、云效、CDN 等多款产品的 PaaS 内核；在社区中，招商银行、第四范式、中国电子、Napptive 等大量国内外公司也正在企业的平台工程中展开 KubeVela 的落地实践。
在最近 Gartner 发布的“2023 年十大重要技术趋势”中，“平台工程”（Platform Engineering）这一项和 KubeVela 的定位不谋而合。KubeVela 正在成为平台工程的最佳范式。记得一次社区例会上，社区的一位企业用户代表在分享他们的实践方案时说了这样一段话：“通过使用 KubeVela，目前在我们的团队，产品、后端、前端甚至是交付同事之间的沟通语言由原来的 Kubernetes 技术概念完全变更成了 OAM 的标准化概念，我们不再需要向具有不同技术背景的同事去解释技术，特别是 Kubernetes 复杂生态的技术。平台化、标准化理念正在公司生根发芽。”
云原生技术的普及催生了全新的应用开发方式，其带来的技术水位的持续上移，将会将应用的交付和管理带向成熟和统一。也许这条路还很长，但我们相信，在这场面向应用交付标准的冲锋中，KubeVela 的贡献势必会留下浓墨重彩的一笔。
没有 NGINX 和 OpenResty 的未来：Cloudflare 工程师正花费大量时间用 Rust 重构现有功能
开源意味着不问责，我们准备好应对比 Log4Shell 更大的安全危机了吗？｜Log4j 一周年特别报道
你也被火爆全网的 ChatGPT 惊艳到了吗？你也在思索下一代“人机交互”的理想形态是怎么样的吗？机会来了！这一次，让我们相约 3 月 11 日北京线下，看专业学者分享研究成果，听技术大佬畅谈实践经验。探讨智能对话新方向，展望人机交互新未来。OGeek 小布沙龙与您不见不散！更多详情可扫描下方二维码或阅读原文了解更多。